Currently, a multiple of devices are performing communication with each other by using Internet protocol. To offer mobility support to the mobile devices, IETF (Internet Engineering Task Force) defines a mobility support in IPv6 as described in the Non-Patent Document 1 given below.
In the Non-Patent Document 1, the mobility support is accomplished by introducing a home agent (HA) to a home network. A mobile node registers a care-of address (CoA) acquired in an external link at the home agent by using a BU (Binding Update) message. By the BU message, the home agent can create a binding between a home address (HoA), which is a long-term address acquired at the home link, and the care-of address.
The home agent intercepts a message directed to the home address of the mobile node, and it has a function to encapsulate a packet (this means to turn a packet to a payload of a new packet, and it is known as packet tunneling) and to transfer the packet to the care-of address of the mobile node.
One of the problems in MIPv6 (Mobile IPv6) is that MN must perform updating to one or more of HAs and CNs (correspondent nodes). This means that the load of signaling is increased for MN, which is moving at high speed. Further, it is necessary to perform RR (return Routability) or to transmit the BU message when the network connection is changed, and average handoff time at the change of the network connection is increased.
Therefore, in a session relating to a flow or a connection, considerable time is required for handoff processing. As a result, jitter or packet loss may occur. The jitter as such is not very desirable for applications requiring high immediacy such as voice-over IP (VoIP), multi-media streaming, video streaming, etc. The packet loss is not desirable for a flow, which transmits an important text and/or data information. Further, when TCP (Transmission Control Protocol) is used for transmission of important data, the throughput of TCP may be decreased due to the packet loss.
To solve such problems relating to MIPv6, attention is currently focused on a Network-based Local Mobility Management (NetLMM) protocol, and the protocol of this type is now studied and discussed in the NetLMM Working Group of IETF. The network-based local mobility management is to perform management on the mobility of a node by the network instead of a mobile node in a network segment, which is logically localized.
To attain the object as described above, MN acquires the same prefix in a local domain. In this prefix, hierarchy of routing is at a higher position so that benefit can be obtained from the local mobility management, and it should be acquired from a router, which is positioned on a default routing path of each MN in the local domain.
It is desirable that, in the routing, which is present at the top of this prefix (the uppermost position as seen from the viewpoint of hierarchy), reachability information of this prefix (a route based on the prefix) is maintained and the route based on the prefix is managed.
The best network-based local mobility management protocol as conceived by the NetLMM Working Group is the PMIPv6 (Proxy Mobile IPv6) disclosed in the Non-Patent Document 2 as given below. The PMIPv6 is so designed that the mobility of an IPv6 host can be supported in a local area of the network. The PMIPv6 can support the mobility of the IPv6 host, which is not provided with a client type mobile IPv6 (CMIPv6) stack.
In the PMIPv6, a local management signaling in a local domain to bind a local PMIPv6 prefix to a currently reachable address of MN is processed on the network side, and this is also useful for a node which has the CMIPv6 stack.
When MN having the CMIPv6 stack moves in a PMIPv6 domain (i.e. a management domain where PMIPv6 is provided) and the term of the binding registered at one or more HA and/or CN is going to expire, it may be necessary to transmit a global registration to associate an address (care-of address) of the PMIPv6 domain with the home address.
When MN with the CMIPv6 stack moves from a PMIPv6 domain to another domain or to another domain where the network-based local mobility management is not supported, it must transmit global registration to one or more HAs and/or CNs. Such global registration may have to be carried out when MN having the CMIPv6 stack enters a PMIPv6 domain.
When MN is connected to a PMIPv6 domain, MN provides NAI (Network Access Identifier) while it is connected with MAG (Mobile Access Gateway). MAG is a router which carries out proxy local registration on behalf of a mobile terminal (including IPv6 host; hereinafter referred as “MN”), and which is directly connected to MAG or under the management of MAG.
NAI is delivered to an AAA server (Authentication, Authorization and Accounting server) for the purpose of authentication. The AAA server (a local server (LS)) sends a reply to notify the success of authentication to MAG when it authenticates the network connection of MN, and it provides local PMIPv6 domain parameters of the home link or MN. These parameters include: a prefix unique to each MN, an address of LMA, a moving policy of MN, address arrangement of mode (stateless or stateful), ability of MN (ability for IPv6, MIPv6-mounted, etc.). When MAG acquires the parameters of MN as such, it emulates a home link and/or a local home link and transmits a proxy BU (PBU: Proxy BU) to LMA at the same time.
The PBU or the local registration to be carried out by MAG is the same as the BU of MIPv6 except the setting of detailed parameters such as the setting of a flag to indicate that the processing is a proxy BU. By carrying out the PBU, a reachable state to MN is created at LMA. Basically, LMA can reach the prefix of MN as acquired in the PMIPv6 domain, and a reachable address to the prefix is the address of MAG. Specifically, LMA has a type of information, where the prefix of MN is associated with the address of MAG to which MN is connected. MN configures an address by using a prefix received in the PMIPv6 domain in stateless or stateful address arrangement mode. Because each MN acquires a unique prefix, the reachability to MN can be sufficiently accomplished at a prefix-based cache of LMA.
All data packets reaching LMA are tunneled to MAG where MN is connected. The same also applies in reverse direction, and data packets transmitted from MN are tunneled to LMA from MAG. In the neighbor cache table of MAG, a PMIPv6 local address of MN and a binding with the link layer address are included, and these are referred when the packets are transmitted to MN.
A mobile node of multi-homing in wider sense is an MN, which has a plurality of interfaces (each of the interfaces may have different access technique), or an MN, which has an interface able to configure different addresses on the same interface. For instance, advantages of a multi-home host with various types of scenarios are described in the Non-Patent Document 4 as given below, and it can be foreseen that MN can have a plurality of interfaces or can have the function to process a plurality of prefixes later. However, the PMIPv 6 described in the Non-Patent Document 2 is designed by taking a mobile node having a single interface into account, and this PMIPv6 lacks the function of multi-homing support.
Also, the Non-Patent Document 7 as given below discloses a method to provide a multi-homing supporting function to a home agent when a node of CMIPv6 moves to a foreign domain. The multi-homing support function as disclosed in the Non-Patent Document 7 is a mechanism, by which the packets of MN can reach via different care-of addresses associated with one or more MN interfaces to carry out the advantages of multi-homing. When MN moves to a foreign domain of CMIPv6, a home agent that is a logical anchor point of home prefix of MN, must maintain binding information relating to the care-of address of MN for executing the multi-homing. The binding information as given above is a type of information, which is useful to perform mapping of various care-of addresses relating to one or more MN interfaces to the home address.
In order to maintain different types of binding at the same time, a BID (Binding Identifier Number) is used as described in the Non-Patent Document 7. The BID as given above is a type of identification information to uniquely identify an interface or the care-of address relating to the interface. BID is generated by a moving MN, and it is transferred to HA at the time of binding registration. By using BID, HA can maintain the registration to accomplish the reachability via different care-of addresses to a single home address. In general, this type of mechanism is called a multi-homing support mechanism. In the current PMIPv6, no consideration is given on the realization of this multi-homing support mechanism.
In the 3rd generation partnership project (3GPP), it is tried to accomplish global different types of network architecture set up by different types of radio access networks such as WLAN (Wireless Local Area Network), cellular network (3G network), WiMAX type wireless wide area network WWLAN (Wireless Wide Area Network), etc. This global different types of network architecture is used when seamless mobility should be realized or to support different types of application services such as real time video, VoIP, transmission of important data, etc.) under the condition of high QoS (Quality of Service).
In the Non-Patent Document 6 as given below, it is described that the possibility is high to adopt PMIPv6 as a local mobility management protocol of the 3GPP local domain. The 3GPP local area is set up by 3G cellular access network or by a trusted (reliable) WLAN or non-trusted (non-reliable) WLAN, etc. Further, there may be a case where an MN having a plurality of different types of interfaces moves in the 3GPP network as described above and simultaneous connections by different types of interfaces are required to attain multi-homing effect. Therefore, it appears that PMIPv6 provided in 3GPP must be able to carry out some kind of multi-homing support.
The Non-Patent Document 5 as given below describes various problems which may arise when MIPv6 and PMIPv6 perform interaction with each other. In this document, description is primarily given on the problems relating to an MN, which is mounted with CMIPv6 stack and is subscribed in PMIPv6 service. In the Non-Patent Document 2 and the Non-Patent Document 5, it is described that LMA further has HA function. In LMA of such dual mode, the function of LMA of PMIPv6 and the function of HA of MIPv6 are fulfilled by a single communication device, and this is referred as a concurrently provided LMA/HA (referred as “LMA/HA” in the present specification).
LMA/HA fulfills the function as a PMIPv6 home LMA to a node, which has a home address, configured from the prefix of LMA (a prefix belonging to the control of LMA and being unique to each MN). Also, LMA/HA fulfills the function as a foreign LMA to a node which has a home address not using the prefix of LMA and which has moved to PMIPv6 from outside. Further, LMA/HA fulfills the function as HA of MIPv6 to a node which is moving to other domain, and can carry out position management (management of care-of address) of this node. Also, when LMA/HA is a home agent of a specific node and this node starts to move in a PMIPv6 domain, which is a home domain, LMA/HA fulfills the function as a home LMA. In this case, position registration signaling is carried out at LMA/HA. When the MN as given above moves to another foreign domain, the same LMA/HA fulfills the function as HA of MIPv6, and receives the registration of MIPv6 from MN directly.
In general, as disclosed in the Non-Patent Document 2 or in the Non-Patent Document 5, for an MN which has only one interface and which is associating one address with this interface, only one cache entry can be used at LMA/HA. With regard to the MN which has only one interface, it is necessary to arrange that only one cache entry can be registered to one MN to connect either one of arbitrary connection points of a home PMIPv6 domain, a foreign domain, or a home link, and LMA/HA should have only one cache to a certain MN.
Further, the Patent Document 1 as given below discloses a method to offer a local area mobility management of network via a network access router in the domain to the MN in moving (mounted with MIPv6 stack). In this case, an anchor to carry out the local mobility management is called a mobility anchor (MA), and its prefix is notified from an access router. As a result, MN can configure a care-of address and can register MIPv6 to HA or CN.
In the Patent Document 2 as given below, a technique is disclosed, according to which MA can resolve a race condition by using a sequence number in the registration of MIPv6 in the local mobility management domain. Further, the Patent Document 2 as given below discloses information to notify two prefixes to MN. In this case, one of the two prefixes is a local prefix (e.g. it is a prefix to be notified from AR (access router), i.e. address of AR), and the other is an address of a mobility agent (MA). A local network segment where MN receives MA address is called a local mobility domain. MN configures two care-of addresses.
The address as configured by MN from a prefix related to AR is called a local address, and an address configured from the prefix of MA is called a global address. Each time the sub-network is changed in the local domain, MN configures a local care-of address and notifies this local address to MA. Also, only in case the mobility agent has been changed, MN configures a global address and notifies it to HA or CN. A binding to be notified to HA or CN is a binding, which associates the home address of MN with the global address of MN.    [Non-Patent Document 1] Johnson, D. B., Perkins, C. E., and Arkko, J.: “Mobility Support in IPv6”; Internet Engineering Task Force Request for Comments 3775; June 2004.    [Non-Patent Document 2] Gundavelli, S., et al.: “Proxy Mobile IPv6”; Internet Engineering Task Force (IETF) Working Group Draft: draft-sgundave-mip6-proxymip6-02.txt; Mar. 5, 2007.    [Non-Patent Document 3] Damic, D, et al.: “Proxy Mobile IPv6 Indication and Discovery”; Internet Engineering Task Force (IETF) Working Group Draft: draft-damic-netlmm-pmip6-ind-discover-01.txt; Jun. 19, 2007.    [Non-Patent Document 4] Ernst, T., et al.: “Motivations and Scenarios for Using Multiple Interfaces and Global Addresses”; Internet Engineering Task Force (IETF) Working Group Draft: draft-ietf-monami6-multihoming-motivation-secenario-02.txt; Jul. 12, 2007.    [Non-Patent Document 5] Giaretta, G., et al.: “Interactions between PMIPv6 and MIPv6: scenarios and related issues”; Internet Engineering Task Force (IETF) Working Group Draft: draft-giaretta-netlmm-mip-interactions-01; Jul. 6, 2007.    [Non-Patent Document 6] “3GPP System Architecture Evolution: Report on Technical Options and Conclusion”; 3GPP TR 23.882, V I.9.0; April 2007.    [Non-Patent Document 7] Wakikawa, R., et al.: “Multiple Care-of Addresses Registration”; Internet Engineering Task Force (IETF) Working Group Draft: draft-ietf-monami6-multiplecoa-03.txt; Jul. 9, 2007.    [Patent Document 1] international Patent Publication Application No. WO-03-107600.    [Patent Document 2] U.S. Pat. No. 6,992,995.
However, problems may arise because PMIPv6 does not support multi-homing and LMA/HA can maintain only one cache entry relating to a certain MN. Even when it is so designed that PMIPv6 can formally support multi-homing, problems may arise. In the following, description will be give on these problems:
In FIG. 1A, MN 10 has two interfaces having different types of access technique. MN 10 is first connected to a home PMIPv6 domain 100, which is a home domain, and it is connected to a global Internet 102 via this home PMIPv6 domain. It is supposed here that one of the interfaces moves from the home PMIPv6 domain to a foreign domain after time elapses, while the other of the interfaces is still connected to the home PMIPv6 domain. One of the interfaces of MN 10 is an interface of a type using WLAN access technique, while the other of the interfaces is an interface of 3G type. Although not shown in the figure, there may be a case where the home PMIPv6 domain 100 and the WLAN access network (foreign domain 101) are connected without passing through the global Internet 102 (e.g. in case connection is made via a node such as LMA, MAG, etc.)
It is also supposed here that MN 10 is provided with CMIPv6 stack. Further, it is supposed that the 3G interface is directly connected to MAG 20 via a radio link 11 and that the WLAN interface is directly connected to MAG 21 via a radio link 12. Also, it is supposed that the WLAN interface is connected to a WLAN, which is a non-trusted (non-reliable) WLAN as seen from 3G network as described in the Non-Patent Document 6. It can be considered that the function of MAG is provided to AR in a trusted (reliable) WLAN.
The prefix which is received by MN 10 after it is connected to this PMIPv6 domain via one of a plurality of interfaces, is a home prefix, and the PMIPv6 domain 100 may be described as a home PMIPv6 domain. This home prefix may be set up in advance at MN 10, or may be acquired from a DHCPv6 server (not shown) or from an AAA server 30 during boot strapping. Therefore, when MN 10 receives the home prefix by RA (Router Advertisement) after receiving a layer 2 authentication, it can be promptly identified that this is the home network. In this case, MN 10 does not carry out mobility-related position update signaling between LMA/HA 40 and itself.
Further, it is supposed here that MN 10 is first connected to MAG 20 via the 3G interface. In this case, MN 10 receives a home prefix via the 3G interface by RA signaling as described above. MN 10 configures an address in the 3G interface by using stateful or stateless address arrangement mode.
MN 10 may use the address as configured for the 3G interface as a home address of MIPv6 in both of the interfaces. In the following, it is supposed that MN 10 uses the address as configured for the 3G interface as a home address of MIPv6 in both of the interfaces. Because the DHCPv6 server offers the same address to both of the interfaces according to NAI and prefix information, the same address may be configured for both of the interfaces when stateless address configuration is carried out.
When parameters of MN 10 are acquired from a local AAA 30, MAG 20 issues a proxy BU 60 to LMA/HA 40. A binding cache (BC) entry created by a proxy registration (PBU) 60 is a first entry of BC 50 as shown in FIG. 1B, for instance. Description will be given now by using a binding cache with such arrangement, while actual way of management is diverse as to how these entries are managed. For instance, entities to fulfill the functions of LMA and HA are installed separately, and these binding caches are placed under management separately for PMIP and for CMIP, and associated processing is performed between entities having the functions of LMA and HA while notifying to each other.
Further, it is supposed here that the home PMIPv6 domain 100 has a function to perform multi-homing support. This multi-homing support function means that LMA/HA can maintain simultaneous connection binding by using an interface identifier (IF-ID) or BID similarly to the case as disclosed in the Non-Patent Document 7. Further, it is necessary to create a plurality of bindings relating to the same prefix of MN 10, and LMA/HA 40 must be able to discriminate simultaneous connection by the same MN 10 by using another parameter such as BID, for instance, to create a plurality of bindings relating to the same prefix by PBU transmitted to each of the two interfaces of MN 10.
It is supposed here that each of the interfaces of MN 10 can acquire only one prefix (a prefix managed by LMA/HA 40 and being specific to MN 10). Therefore, it is possible to discriminate the bindings by the same MN which is making connection via different interfaces by using an interface ID such as MAC (Media Access Control) address, BID, etc.
Also, when a plurality of prefixes are notified and are processed by one interface, the use of BID would be more appropriate when a plurality of bindings are discriminated by LMA/HA 40. In FIG. 1A, it is supposed that BID information is included in PBU 60. This BID is offered by MN 10 or AAA 30, or it is generated by MAG 20. There are many methods to generate BID, and any method as desired may be used.
When the first entry of BC 50 is checked, it is seen that a reachable condition relating to the home prefix of MN 10 is associated with the address of MAG 20 (i.e. MAG 20.CoA). This address of MAG 20 is a care-of address of the 3G interface of MN 10 or it is a proxy care-of address of the 3G interface of MN 10.
Because PBU 60 is based on PMIPv6 registration and no sequence number is used on PBU, no entry is present in the field of the sequence number (N/A). Also, PBU has a time stamp option field, and time information included in the time stamp option of PBU 60 is stored in the binding entry relating to PBU 60.
Further, it is supposed that, subsequent to the connection of 3G interface, connection is made to MAG 21 via the WLAN interface of MN 10. After L2 authentication has been successfully performed, the WLAN interface receives the same home prefix as a prefix as seen from the 3G interface. When notification of the successful authentication is received from AAA 30, PBU 61 is sent to LMA/HA 40.
After being connected to MAG 21 only for a short time, the WLAN interface of MN 10 promptly moves and is connected to a foreign domain 101. This foreign domain 101 is also connected to the global Internet 102. The foreign domain 101 may be another 3GPP domain or a different access network such as WiMAX, WLAN, etc. or may be a network where a radio system and a fixed system are coordinated by means such as FMC (Fixed Mobil Convergence) or a network relating to a network arrangement under management of higher order such as NGN (next Generation Network), or the reliability with these networks may be high or low. Further, the home PMIPv6 domain 100 and the access network of WLAN (foreign domain 101) may be connected together without passing the global Internet 102 (e.g. connection may be made via a node such as LMA, MAG, etc.). There are essential problems despite of the difference in the network arrangement, and description will be given below in the present specification by taking an example on an arrangement of FIG. 1A.
In the connection to the foreign domain 101, it is supposed here that the WLAN interface makes connection to AR 22 via a radio link 13. Quick change of connection of the WLAN interface of MN 10 is schematically shown by an arrow mark 14 in FIG. 1A. MN 10 may receive a nomadic prefix from AR 22. After receiving this prefix, MN 10 configures a care-of address and carries out MIPv6 BU 62 to LMA/HA 40.
It is assumed here that this BU registration 62 reaches LMA/HA earlier than PBU 61 from MAG 21 (i.e. PBU relating to the connection before the switch of the interfaces). In this case, a phenomenon normally called a race condition (a competitive condition) occurs because the connection to MAG 21 has lasted only for a very short time. Also, a race condition may occur when PBU 61 arrives later than BU 62 of MIPv6 (CMIPv6) due to congestion of the packets in the home PMIPv6 domain.
When MIPv6 BU 62 reaches LMA/HA 40 earlier, registration of MIPv6 is prepared at LMA/HA 40. For instance, it is supposed here that PMIPv6 and CMIPv6 caches are placed under management in a space of one cache or one address at LMA/HA 40, LMA/HA can identify the difference of caches of PMIPv6 and CMIPv6 of a specific interface of MN 10 by using NAI, for instance. Also, in the second entry of BC 50, a CMIPv6 cache is present. At BC 50, the interfaces can be uniquely identified depending on the field of IF-ID/BID.
For a CMIPv6 binding, a sequence number included in the BU message is stored at the entry of the sequence number (Seq#). In the CMIPv6 binding, there is no information, which should be placed in the time stamp field. After the elapse of a short time, an older PBU 61 as forwarded from MAG 21 may reach LMA/HA 40. In this case, only one binding to assign either one of PMIPv6 or CMIPv6 to a certain interface as described above is maintained, and a correct CMIPv6 binding of BC 50 may be overwritten by an older PBU 61 from MAG 21. This is represented by the erasing of the second entry of BC 50 in FIG. 1B.
The erroneous entry as set up above may receive proxy registration deletion from MAG 21, or MN 10 may be kept in a condition usable by LMA/HA 40 until the binding refresh BU reaches from the WLAN interface. Until the erroneous entry will be deleted, all packets to be transmitted and received at the WLAN interface will be lost. As a result, the network cannot offer services such as load balance, fault tolerance, bi-casting, etc. (services based on the multi-homing function), and it is not possible to receive the benefit of multi-homing.
In general, the problem that the current CMIPv6 cache is overwritten by older PMIPv6 registration is called PMIP/CMIP race condition. Those skilled in the art would easily understand that similar problem may occur when the WLAN interface of MN 10 is first connected to a foreign domain and it goes back to the home PMIPv6. In such case, the older CMIPv6 cache may be registered instead of the current PMIPv6 cache.
According to the technique disclosed in the Patent Document 1, when MN moves in a local mobility management domain, an access router fulfills the function as a proxy of MN and carries out local position registration signaling of MN to MA. This signaling method is the same type of the method as the method of HMIPv6 or MIPv6.
According to the technique disclosed in the Patent Document 2, MA is not a home agent of MN but it is a mere mobility agent. Therefore, as explained in connection with FIG. 1A and FIG. 1B, no race condition occurs where CMIPv6 binding is overwritten by the PMIPv6 binding. When MN moves from the local mobility management domain to the other domain, old local registration in the old domain (i.e. the domain before the moving) is deleted, and management of a new local registration is executed in the new domain. Therefore, according to the technique disclosed in the Patent Document 2, there is no possibility to cause a race condition between a PMIPv6 binding in the PMIPv6 domain and a CMIPv6 binding in the CMIPv6 domain.
In the technique disclosed in the Patent Document 2, MN carries out local registration to MA. However, the race problem in the local mobility management signaling of the local domain can be solved by using a sequence number just as in the case of MIPv6. In the technique disclosed in the Patent Document 2, MA is a mere local mobility management anchor and it is not a home agent. Accordingly, when MN moves from a local domain, new registration of MN is not notified to MA of the local domain, to which it has been connected before the moving. Therefore, there is no possibility to cause a race condition where the CMIPv6 binding is overwritten by the PMIPv6 binding as explained in connection with FIG. 1A and FIG. 1B. Thus, the technique disclosed in the Patent Document 2 cannot solve the problem relating to the present invention.